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Abstract. For sustainable Exploration Missions the need exists to assemble systems-of-systems in space, on the Moon or 
on other planetary surfaces. To fulfill this need new and innovative system architecture is needed that can be satisfied 
with the present lift capability of existing rocket technology without the added cost of developing a new heavy lift 
vehicle. To enable ultra-long life missions with minimum redundancy and lighter mass the need exists to develop system 
software and hardware reconfigurability, which enables increasing functionality and multiple use of launched assets 
while at the same time overcoming any components failures. Also the need exists to develop the ability to dynamically 
demate and reassemble individual system elements during a mission in order to work around failed hardware or changed 
mission requirements. Therefore to meet the goals of Space Exploration Missions in Interoperability and 
Reconfigurability, many challenges must be addressed to transform the traditional static avionics architecture into 
architecture with dynamic capabilities. The objective of this paper is to introduce concepts associated with reconfigurable 
computer systems; review the various needs and challenges associated with reconfigurable avionics space systems; 
provide an operational example that illustrates the needs applicable to either the Crew Exploration Vehicle or a collection 
of “Habot-like” mobile surface elements; summarize the approaches that address key challenges to acceptance of a 
Flexible, Intelligent, Modular and Affordable reconfigurable avionics space system. 


INTRODUCTION 

Dynamic computer systems have evolved in the Computer industry due to the development of a standardized 
interface that supplies both power and information and is “hot swappable” (i.e. can be coupled and decoupled while 
the operating system is running). Another key element of the dynamic computer system is plug-and-play 
technology. Plug-and-play technology employs a standard mechanism that can detect when a component has been 
added or removed from the system in addition to determining the component type. Once the newly added 
component is identified a service discovery manager determines how to communicate with it and then integrates it 
into the existing system. From a high level this capability is needed to assemble system-of-system elements for 
Exploration Missions. The discriminator is that personal computer systems are traditionally unreliable and not 
certified for a real-time, deterministic, mission critical avionics systems. The National Aeronautics and Space 
Administration is currently investigating adapting this high-level concept of evolvable, modular, reconfigurable, 
reprogrammable, and distributed software to develop dynamic avionics architectures that perform critical functions. 
Modular FPGA-based avionics with flexible control software can also be used in various robotic applications. They 
can serve as single-axis motion controllers with sensory feedback and fault tolerant computing capabilities. They 
can be located close to each actuator to reduce complex cabling costs. They can also serve as controllers for robotic 
arms coordinating several degrees-of-freedom. All these components require the acquisition of various sensor 
information, the fusion and processing of that knowledge, and the generation of behaviors that result in either 
estimated knowledge or system motion. However, to operate reliably in various environments and under different 
system configurations, these controllers must be able to learn and adapt to changes in their environment. These 
changes can range from large variations in the load experienced by manipulator joints, variations in terrain 
roughness for mobility platforms, variations in lighting condition for vision applications, or. variations in the quality 



of the measurements from different fidelity sensors. Dynamic avionics architectures require technology development 
to achieve strategic goals in four main areas: 

> Flexibility (long-term survivability) - to mitigate and recover from failures due to random events, 
design errors, and wear-out mechanisms; protect against propagating failures across system-of- 
system interfaces. 

> Intelligence (optimal knowledge management) - to manage dynamic resources such, as power, fuel, 
air, communication, processing, memory. Develop redundancy management strategies based on 
available capabilities. 

> Modularity (evolvability and adaptability) - to support upgrades and changes to the hardware 
configuration during the mission; reducing obsolescence issues and enabling requirement changes 
due to the explorative nature of the mission. 

> Affordability (long-term operation of the spacecraft) - to reduce sustaining, software lifecycle and 
operation costs 

The objective of this paper is to introduce concepts associated with reconfigurable computer systems; review the 
various needs and challenges associated with reconfigurable avionics space systems; provide an operational example 
that illustrates the needs applicable to either the Crew Exploration Vehicle or a collection of “Habot-like” mobile 
surface elements; summarize the approaches that address key challenges to acceptance of a Flexible, Intelligent, 
Modular and Affordable reconfigurable avionics space system. 


NEEDS AND CHALLENGES OF A DYNAMICALLY CONFIGURABLE 
AVIONICS SYSTEM FOR EXPLORATION MISSIONS 

Current designs of modular space structures, such as the International Space Station (ISS), are modular only from a 
physical perspective. The ISS avionics architecture is a static hierarchal system where each physical configuration 
change requires updates to the flight software. These updates could be as minor as invoking configuration files to as 
major as complete replacement of functional software. Each flight software update must be completely verified and 
validated on the ground prior to installation on-orbit for each new hardware configuration. 

Lack of standardized power and data bus configurations between each of the ISS nodes limits the way hardware 
components can be interchanged to support resolution of on-orbit hardware failures or to accommodate changes in 
mission requirements. Other factors that contribute to limiting hardware interchangeability include an inflexible 
avionics architecture; software designed to support hardware constraints for specific components; the cost of 
managing a large number of potential variations in hardware configurations; and the lack of standardized interface 
ports for power and data communications. 

If the current ISS avionics system does not support dynamic hardware re-configuration then why should future 
exploration systems require such a capability? The answer to this question can be found by examining the following 
Level 0 Exploration Requirements: 

(1) “NASA shall implement a safe, sustained, and affordable robotic and human program to explore and 
extend human presence across the solar system and beyond.” 

(2) “NASA shall acquire and exploration transportation system to support delivery of crew and cargo 
from the surface of the Earth to exploration destinations and to return the crew safely to Earth.” 

The key goal stated by these two Level 0 requirements is to implement a safe, sustained, and affordable human 
presence across the solar system and beyond. A single, “one-size-fits-all” transportation system will not support this 
goal .as the mission requirements for reaching human destinations such as the Moon and Mars are vastly different. 
The Moon is a three-day journey using current chemical propulsion systems. The hardware required for a human 
lunar return mission includes: Propulsion Module that supports trans-lunar injection, Junar breaking, trans-earth 
injection, Earth breaking; Crew module that also serve as a Crew return module, Ascent/Descent .modules; and lunar 



surface elements such as habitation, storage, power, mining, In-Situ Resource Utilization modules. A journey to 
Mars, on the other hand, will require an eight to ten month transit time with either a thirty day or eighteen month 
stay. The hardware requirements will be geared toward long-duration space travel and will most likely include a 
larger habitation module, a different propulsion module, expanded power requirements, and perhaps a system that 
supports artificial gravity for the long journey between planets. Elements for each of these missions could be 
developed separately and managed as individual configurations; however, this option would fail to meet the 
sustained and affordable section of the Level 0 requirements. Clearly any system that supports delivery of crew and 
cargo from the surface of the Earth to multiple exploration destinations will need to support a building block 
infrastructure where elements can be connected in-space to build a system-of-systems capability. This capability 
must be reconfigurable to support safe recovery from failures or unforeseen changes in requirements due to the 
explorative nature of the mission. 


The Intelligent Flight Control (IFC) 
research program address adaptive 
aircraft control (Kaneshige et al., 2001), 

(Gundy-Burlet et al., 2003), 

(KrishnaKumar et al., 2003), (Kaneshige 
et al., 2000). Major features of IFC 
technology are its near plug-and-play 
capability and its ability to adapt to 
unforeseen events through the use of 
self-learning neural control architecture. 

Unforeseen events can include sudden loss of control actuators, engine thrust demand changes, and other causes that 
may result in the departure of the vehicle from safe conditions. NASA ARC and NASA DFRC have implemented 
the IFC architecture in many different vehicle simulations varying from small unmanned aircraft to large transport 
aircraft and highly maneuverable fighter aircraft (see Figure 1). This experience gives us a firm foundation on which 
to build the proposed plug-and-play architecture. 



FIGURE 1. Various Aircraft Simulations Tested Using IFC in 
a Near Plug-and-Play Manner. 
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FIGURE 2. Project Goal is a Plug and Play Control Hardware. 

The end product of our research and development, as shown in Figure 2, is a hardware prototype of a plug-and-play 
controller. To successfully arrive at the proposed architecture we need to address the following: 

> Control requirements and standardization 

> Plug and Play architectural details 

> FPGA hardware design and implementation 
These are discussed next. 


Control Requirements 

Control requirements vary widely across the needs of space exploration. These requirements help map the domain of 
control paradigms to the range of all controllable systems as shown notionally in Figure 3. Examples of such 
requirements are: 

CEV: One of the key elements of the CEV avionics system will be an environment where changes 
in configuration, such as switching to a different propulsion module between Earth/Lunar missions 
and missions beyond near-Earth space, will be accomplished without overhaul of the basic 





command and control software. To accomplish this, the hardware must be abstracted to an 
appropriate level such that changes in technology chemical/nuclear/solar can be hidden from the 
control software. 

Robotic Manipulator: Coordinated motion control for a manipulation or a locomotion system 
requires hard real-time guarantees to generate a smooth motion profile, while look-and-move 
navigation and obstacle avoidance algorithms require the less strict constraints of a soft real-time 
environment. In this work, we will address both types in the context of robotic systems. 

Rover: Surface exploration robots can be wheeled vehicles, legged mechanisms, or a hybrid of the 
two. Controllers for legged system have different requirements and operational constraints than 
wheeled systems. Also, controllers need to integrate with systems that have different hardware 
architectures. Consider several hardware architectures of various rovers such as Sojourner, MER, 
and numerous research rovers including Rocky 7, Rocky 8, K9, and FIDO. Their respective 
hardware architectures range from fully centralized to fully distributed. Modular controllers have 
to be integrated and operated in conjunction with other systems that can have different hardware 
topology. 



FIGURE 3. GNC Algorithms to GNC Features Mapping. 


Plug and Play Control Architecture 

Figure 4 illustrates a three component plug-and-play enabled GNC avionics architecture that accommodates (1) a 
maneuvering controller for high level mode changes and targets, (2) a guidance controller for generating outer-loop 
commands, and (3) an inner loop stability controller sending commands to the vehicles actuators. Our architecture 
will allow modular plug-and-play components to be swapped into this system to provide the necessary functionality 



FIGURE 4. A Plug-and-Play GNC Architecture 





needed to fulfill mission and vehicle control requirements. These modular components can be removed from the 
system and tested in isolation, enabling a high level of maintainability and testability of modules in the field. 

A plug-and-play enabled architecture with this capability has many requirements, and standardization may be highly 
influenced by the breadth of the platforms considered. The architecture must be able to recognize the devices and 
establish communication, requiring a level of standardization be imposed on the architecture that specifies the 
communication protocol, data bus, power requirements, physical interface requirements, etc. Protocols must also be 
established to allow the necessary modifications to the avionics system as well as the plug-and-play modules to 
accommodate a previously unknown module configuration in a wide spectrum of possible platforms such as rovers 
and spacecraft. For instance, sensor information and actuator configurations will be often radically different on each 
platform. An intelligent flight controller may require different configuration data for each platform than a 
hierarchical PID controller. Standardization requirements definitions will establish the communication protocols to 
allow this information to be passed between the system and modules, and must define the tradeoff between 
flexibility and complexity of the architecture to ensure usability. 


FPGA Hardware Implementation 

Field Programmable Gate Arrays (FPGAs) are programmable devices that have reconfiguration capability that can 
be used for fault recovery or performing multiple tasks. Figure 5 depicts a typical failure scenario that the FPGA can 
encounter. After being partly damaged by an external or internal source, the FPGA can be reprogrammed using its 
undamaged gates. This capability can be used to correct latent design errors as well as on-chip and off-chip failures. 
Such autonomous repair capability provides an alternative to device redundancy that offers potential weight savings 
in a space mission. At the same time the characteristics of all the different failures need not be diagnosed in order to 
initiate repair. The second possibility includes multi-tasking where an undamaged FPGA can be reprogrammed to 
perform a different function. This capability is also attractive since it offers the plug-and-play characteristic to any 
device that uses FPGAs. 
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FIGURE 5. Fault-Tolerant FPGA 

Reconfiguration of the FPGAs can be analyzed as an optimization problem where the gates need to be 
reprogrammed to provide the desired functionality from the particular device. NASA ARC has developed an 
evolutionary fault-recovery system that employs genetic representation (Lohn et al., 2003). Evolutionary algorithms 
have the capability of finding the global optimum or the best available solution for the given problem. Using 
software models of the Xilinx Virtex FPGA, we have illustrated several failure scenarios in which the evolutionary 
algorithm was able to evolve the FPGA to provide the same functionality with the unaffected part of the FPGA 
(Lohn, 2002). Evolutionary systems for fault recovery on FPGAs is an important tool in the quest for ever-higher 
levels of fault tolerance in NASA missions. 



Hypothetical Operational Scenario 

The Crew Habitation Module (CHM), launched separately from the Crew Exploration Vehicle Command & Control 
Module (CCM), would contain Advanced Life Support (ALS), a Waste Management System (WMS), and a separate 
Communication system (with a large high gain antenna). The CCM would most likely contain the main Command 
& Control system, Communications system (though this may be limited due to antenna availability) as well as 
Guidance Navigation & Control (GN&C) and a combination of solar and battery power. Since the CHM is launched 
separately it will require a minimal GN&C system as well as a Command & Control system and solar power 
capability. 

When the CCM and the CHM dock, a service discovery process is initiated to determine the capabilities each 
module can provide to the integrated vehicle. The service discovery mechanism then compares each module’s 
capabilities and, when an overlap occurs, selects the optimal capability. For example, the CCM in this example 
would assume overall Command & Control functionality; and since the life support capabilities of the CHM are 
superior its ALS system would be selected as primary while the CCM system would act as a backup or an 
augmentation if needed. Power may be interconnected or isolated as required; and communications would be routed 
through the respective communications subsystem that best meets the quality of service requirements for data 
throughput. If the CHM contains an onboard data recording and retrieval system, as would be required for a mission 
where the Round Trip Light Time (RTLT) is measured in minutes, then the combined CHM/CCM vehicle may 
switch to a reduced telemetry mode where only summary data is transferred to the ground in real-time. All data 
would be recorded locally and could be retrieved by the crew or ground personnel if needed to troubleshoot an 
anomaly. This same scenario would apply to the propulsion module as well as all other Crew Exploration Vehicle 
modules as required to support each unique mission destination. Each module in the CEV system would provide 
services to other subsystem elements. An example of this may be a propulsion module that provides directional 
thrust to the rest of the vehicle and reports updated mass consumption to be used for GN&C calculations as 
propellant is depleted. Likewise the Health Management system may provide health data for the power system to the 
propulsion module so that it can better isolate internal faults. 


Challenges Faced 

Many challenges exist to winning acceptance of this dynamic reconfigurable system design paradigm over the more 
traditional static avionics system. One of the most difficult challenges will be finding an approach that can 
verify/validate that control capability can be maintained despite the dynamic addition and removal of support 
services. This approach must be built on an abstraction technique that can effectively hide hardware details from 
one system to another and an interface that is well tested. This approach however will not be enough to tackle the 
criticality and certification issues. In order to guarantee that a support service provided by one module does not 
impede a critical service on another module, multiple data buses supporting a hierarchy of service levels will be 
required. In this way the dynamic behavior can be isolated and verified in more manageable sizes. The hierarchy of 
services envisioned may be tiered to support the following critical functions: Control, Life Support, and Mission. A 
fourth tier may be needed to address non-critical operations. The service classes associated with each of the tiers are 
as follows: 

> Control: Maximum failure response time is typically on the order of seconds. This would apply 
primarily to GN&C, Power, Propulsion, and Command & Control. 

> Life Support: Maximum failure response time is generally on the order of minutes. This would 
apply primarily to Environment Control, Life Support, and Communications. 

> Mission: Maximum failure response time is usually on the order of hours. This would apply 
primarily to Science Instruments, Data Record & Retrieval, and Human Support Equipment 
(Galley, Waste Management). 

> Non-Critical: No maximum failure response time. This would apply mostly to Crew Information 
Network (email, electronic documentation, multi-media). 



Using this tiered approach each service class would perform the same service discovery process to determine the 
capabilities offered by each peer within its class. From a certification standpoint an exhaustive verification would 
not be required to prove that the communication system does not impact the propulsion system. Likewise it would 
not have to be proven that the Waste Management System does not affect the communications system. 

Another challenge will be differentiating between when a system has failed and when it has been powered down or 
removed. This differentiation is an important consideration when forming an appropriate redundancy management 
strategy and determining a set of corrective actions that can recover a failed function. An approach to solving this 
challenge can be found in several emerging health management algorithms that can learn the behavior of the 
hardware over time. This ability to learn generally requires a large data set from which prognostic and diagnostic 
information can be derived. One strategy for storing These large sets of data would be to adopt the Data Warehouse 
Center of Excellence (COE) capability proposed by Sandia National Labs (Calton, 2004). The Data Warehouse COE 
for prognostic and diagnostic data would be maintained by a neutral party that can facilitate the collection and 
sharing of prognostic data generated through testing performed at multiple government agencies, industries, and 
others. 


CONCLUSIONS 

There are several difficult challenges that must be met before a dynamic reconfigurable avionics system can be 
developed. Automated Service Discovery technologies, which have significantly improved the ability to 
dynamically reconfigure a personal computer, must be evolved to meet the stringent requirements of a critical space-' 
rated avionics architecture. Each challenge must be satisfied by a solution that can be verified, validated and 
certified. Developing a tiered architecture will provide a way to isolate service criticalities as will strong adherence 
to abstraction and interface requirements. “Health management technologies will have to be developed to help with 
the automated service discovery.” (Buckley et al., 2004) Although each challenge must be addressed prior to 
implementing a dynamic reconfigurable avionics system, success in these efforts will be required to enable an 
affordable, sustainable and safe transportation system that can deliver crew and cargo from the surface of the Earth 
to exploration destinations beyond 
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